Adding examples created for previous demo #287
Conversation
…te volume from one hw to another and migrate server profile from one hw to another
| name: "{{ profile_name }}" | ||
| serverHardwareTypeName: "{{ server_hardware_type_name }}" | ||
| enclosureGroupName: "{{ enclosure_group_name }}" | ||
| server_hardware: "{{ server_hardware_name }}" |
There was a problem hiding this comment.
This will not work anymore as server_hardware was not following the style guide from other fields. It should be serverHardwareName now.
| name: "{{ profile_name }}" | ||
| serverHardwareTypeName: "{{ server_hardware_type_name }}" | ||
| enclosureGroupName: "{{ enclosure_group_name }}" | ||
| server_hardware: "{{ server_hardware_name }}" |
There was a problem hiding this comment.
This will not work anymore as server_hardware was not following the style guide from other fields. It should be serverHardwareName now.
| name: "{{ profile_name1 }}" | ||
| serverHardwareTypeName: "{{ server_hardware_type_name }}" | ||
| enclosureGroupName: "{{ enclosure_group_name }}" | ||
| server_hardware: "{{ server_hardware_name1 }}" |
There was a problem hiding this comment.
This will not work anymore as server_hardware was not following the style guide from other fields. It should be serverHardwareName now.
| oneview_server_profile: | ||
| config: "{{ config }}" | ||
| data: | ||
| server_hardware: "{{ server_hardware_name2 }}" |
There was a problem hiding this comment.
This will not work anymore as server_hardware was not following the style guide from other fields. It should be serverHardwareName now.
| name: "{{ profile_name1 }}" | ||
| serverHardwareTypeName: "{{ server_hardware_type_name }}" | ||
| enclosureGroupName: "{{ enclosure_group_name }}" | ||
| server_hardware: "{{ server_hardware_name2 }}" |
There was a problem hiding this comment.
This will not work anymore as server_hardware was not following the style guide from other fields. It should be serverHardwareName now.
| oneview_server_profile: | ||
| config: "{{ config }}" | ||
| data: | ||
| server_hardware: "{{ server_hardware_name }}" |
There was a problem hiding this comment.
This will not work anymore as server_hardware was not following the style guide from other fields. It should be serverHardwareName now.
| config: "{{ config }}" | ||
| data: | ||
| server_hardware: "{{ server_hardware_name }}" | ||
| server_template: "{{ server_profile_template }}" |
There was a problem hiding this comment.
This will not work anymore as server_template was not following the style guide from other fields. It should be serverProfileTemplateName now.
| config: "{{ config }}" | ||
| data: | ||
| server_hardware: "{{ server_hardware_name2 }}" | ||
| server_template: "{{ server_profile_template }}" |
There was a problem hiding this comment.
This will not work anymore as server_template was not following the style guide from other fields. It should be serverProfileTemplateName now.
|
I'd also try improving the example names, perhaps add in a prefix like 'server_profile_' + scenario that it covers. |
There was a problem hiding this comment.
- I really don't understand which is the code difference between the examples. Try to:
a. Create from a template that has the common data and override only the target parameters
b. Comment the playbook specifying exactly what need to be changed to accomplish the examples - Try improving the playbook names, for some of them I couldn't get what you were intending to do
- Try improving the task names, saying exactly what they do, like "Ensures Server Profile X has two SAN connections in volume Y"
| server_hardware_type_name: "SY 480 Gen9 3" | ||
| enclosure_group_name: "SYN107_EG" | ||
| server_hardware_name1: "2-USE722C99W-M, bay 1" | ||
| server_hardware_name2: "2-USE722C99W-M, bay 11" |
There was a problem hiding this comment.
Your file name says it will migrate from 1 to 12, but your file does the miration from 1 to 11. Try changing the name of the example to be more generic, like server_profile_migrate_bays
| powerControl: "PressAndHold" | ||
| delegate_to: localhost | ||
|
|
||
| - name : "Create/Update Server Profile - {{ profile_name1 }}" |
There was a problem hiding this comment.
Specify exactly what are you trying to accomplish with this task
There was a problem hiding this comment.
One caveat here though:
Since we now do not require the server hardware to be off, the bay1 would not even need to be declared in this file, and due to the declarative way of Ansible/Yaml this would just be listing bayX.
The way the example would read, would be simple and not actually adding value.
I'd say we should either create the original SP in this example and THEN change the blade it is using (thus illustrating the change), or drop this example.
There was a problem hiding this comment.
Ok, please review if now it makes sense (five steps in the demo folder).
|
|
||
| tasks: | ||
|
|
||
| - name: Power Off the server hardware |
There was a problem hiding this comment.
Which server hardware? You specified two server hardwares.
Also, don't you need to power off both server hardwares?
There was a problem hiding this comment.
Also, with the current module, I guess you don't need to care if the server hardwares are powered off while operating a server profile, the code already checks and power them off if necessary.
There was a problem hiding this comment.
^ This.
Since it should be working independently of the power state of the server hardwares, this example is illustrating something we don't really want to be doing.
There was a problem hiding this comment.
Ok, I removed the first task and updated the description.
| @@ -0,0 +1,44 @@ | |||
| ### | |||
There was a problem hiding this comment.
This file seems kind of pointless to me, it lists creating a SP based on a template and powering it on, but that is already illustrated in the basic oneview_server_profile.yml example: link
There was a problem hiding this comment.
yes, but it was part of the requested scenarios, I renamed to step 3 and use it again in step 4, so the user can compare tasks.
…rver_template (now using serverProfileTemplateName)
adriane-cardozo
force-pushed
the
adding_more_examples_use_cases
branch
from
e8c2095 to
51deab5
Compare
adriane-cardozo
force-pushed
the
adding_more_examples_use_cases
branch
3 times, most recently
from
54f3f92 to
cc802ba
Compare
|
|
||
| This demo is composed by 5 steps, each one associated with a playbook, that should be executed in the specified order: | ||
|
|
||
| - `step_1_create_server_profile_boot_from_SAN_and_assign_to_bay1.yml`: This playbook exemplifies how to create a server profile with boot from SAN (3PAR) and without using a template. On task #1, the server profile is created (if not already present) and assigned to server hardware in bay 1. You can check all parameters, including those related to the server hardware and those related to the storage as SAN connections and volume attachment. The volume must be ready to use. On task #2, the server hardware is powered on. |
There was a problem hiding this comment.
I'd suggest swapping out this style of writing:
'On task #1,' >>>
For this one:
It performs 2 tasks:
- The server profile is created (...)
- The server hardware is powered on.
This is specially important since the #1 and #2 in this will actually automatically link to issues which is not the intended purpose.
| @@ -0,0 +1,17 @@ | |||
| # Demo | |||
There was a problem hiding this comment.
Also, name of the folder seems weird to me.
Perhaps boot_from_SAN+server_profile_and_volume_migration?
boot_from_SAN&volume_migration?
Not really enjoying any a lot, @tmiotto any bright ideas here?
There was a problem hiding this comment.
Maybe boot_from_san_and_migration There is no need to be that level of specific in the title.
|
|
||
| - `step_1_create_server_profile_boot_from_SAN_and_assign_to_bay1.yml`: This playbook exemplifies how to create a server profile with boot from SAN (3PAR) and without using a template. On task #1, the server profile is created (if not already present) and assigned to server hardware in bay 1. You can check all parameters, including those related to the server hardware and those related to the storage as SAN connections and volume attachment. The volume must be ready to use. On task #2, the server hardware is powered on. | ||
|
|
||
| - `step_2_based_on_server_profile_boot_from_SAN_add_another_volume.yml`: This playbook exemplifies how to add an extra volume attachment to an existing server profile. Task #1 was copied from step 1 and a new volume attachment was added identified by id 2. When this task is executed, the additional volume becomes available to the operating system. |
There was a problem hiding this comment.
For the titles here I'd suggest linking to the example and making the titles more readable, as this does not need to be the name of the file.
I'd then drop the description to the line bellow them:
Step 1 - Do something really amazing
This playbook performs amazing feats! Keep reading to understand the secrets of the universe (...)
Step 2 - Add extra volume to existing server profile
This playbook exemplifies (...)
There was a problem hiding this comment.
Ok. Changed.
| @@ -0,0 +1,17 @@ | |||
| # Demo | |||
There was a problem hiding this comment.
Maybe boot_from_san_and_migration There is no need to be that level of specific in the title.
|
|
||
| - `step_2_based_on_server_profile_boot_from_SAN_add_another_volume.yml`: This playbook exemplifies how to add an extra volume attachment to an existing server profile. Task #1 was copied from step 1 and a new volume attachment was added identified by id 2. When this task is executed, the additional volume becomes available to the operating system. | ||
|
|
||
| - `step_3_create_server_profile_based_on_server_profile_template_and_assign_to_bay12.yml`: This playbook exemplifies how to create a server profile using a server profile template. On task #1, the server profile is created (if not already present) and assigned to server hardware in bay 12. In this case, all settings were configured in the template, including network connections and OS deployment plan to use Image Streamer. On task #2, the server hardware is powered on. |
There was a problem hiding this comment.
You don't need to be that specific in the title, also it would be good not mentioning values that may vary from user to user like bay12. You could simple call this create_server_profile_from_template
There was a problem hiding this comment.
Ok. Changed.
adriane-cardozo
force-pushed
the
adding_more_examples_use_cases
branch
4 times, most recently
from
b739428 to
1d181e0
Compare
adriane-cardozo
force-pushed
the
adding_more_examples_use_cases
branch
from
1d181e0 to
f94b29e
Compare
|
|
||
| ### [Step 4 - Migrate a data volume to another server profile](step_4_migrate_data_volume.yml) | ||
| This playbook exemplifies how to migrate a data volume from one server profile to another. It performs 2 tasks: | ||
| 1. Task copied from step 2 when the extra volume was attached. This task updates the server profile 'profile_san' removing data volume identified by id 2 (returning to the original state - same as in the step 1). |
There was a problem hiding this comment.
Since it is returning the resource to the state it was in step 1, was it really copied from step 2?
There was a problem hiding this comment.
Perhaps:
Updates the server profile 'profile_san' to match its original state in Step 1, removing the data volume identified by id 2.
There was a problem hiding this comment.
Ok. Changed.
| ### [Step 4 - Migrate a data volume to another server profile](step_4_migrate_data_volume.yml) | ||
| This playbook exemplifies how to migrate a data volume from one server profile to another. It performs 2 tasks: | ||
| 1. Task copied from step 2 when the extra volume was attached. This task updates the server profile 'profile_san' removing data volume identified by id 2 (returning to the original state - same as in the step 1). | ||
| 2. Task copied from step 3 to update server profile 'profile_i3s' inserting data volume removed from previous task. The connectionId used by the storage paths need to be updated to match with the SAN connections. In this case, the SAN connection ids in the server profile template were 4 and 5. |
There was a problem hiding this comment.
I'm guessing we can just remove the 'Task copied from' part. Starting on 'Update server profile (...)' seems explanatory enough
There was a problem hiding this comment.
Ok. Changed
| @@ -0,0 +1,28 @@ | |||
| # Demo: | |||
There was a problem hiding this comment.
Perhaps remove this line? It is already inside the demos folder, kind of expected to be a demo.
| 1. Task copied from step 2 when the extra volume was attached. This task updates the server profile 'profile_san' removing data volume identified by id 2 (returning to the original state - same as in the step 1). | ||
| 2. Task copied from step 3 to update server profile 'profile_i3s' inserting data volume removed from previous task. The connectionId used by the storage paths need to be updated to match with the SAN connections. In this case, the SAN connection ids in the server profile template were 4 and 5. | ||
| 1. Updates server profile 'profile_san' to match its original state on step 1, removing data volume identified by id 2. | ||
| 2. Updates server profile 'profile_i3s' inserting data volume removed from previous task. The connectionId used by the storage paths need to be updated to match with the SAN connections. In this case, the SAN connection ids in the server profile template were 4 and 5. |
There was a problem hiding this comment.
Updates server profile 'profile_i3s' inserting the data volume removed from in the previous task. The connectionId used by the storage paths needs to be updated to match with the SAN connections. In this case, the SAN connection ids in the server profile template were 4 and 5.
| @@ -19,8 +18,8 @@ This playbook exemplifies how to create a server profile using a server profile | |||
|
|
|||
| ### [Step 4 - Migrate a data volume to another server profile](step_4_migrate_data_volume.yml) | |||
| This playbook exemplifies how to migrate a data volume from one server profile to another. It performs 2 tasks: | |||
| 1. Task copied from step 2 when the extra volume was attached. This task updates the server profile 'profile_san' removing data volume identified by id 2 (returning to the original state - same as in the step 1). | |||
| 2. Task copied from step 3 to update server profile 'profile_i3s' inserting data volume removed from previous task. The connectionId used by the storage paths need to be updated to match with the SAN connections. In this case, the SAN connection ids in the server profile template were 4 and 5. | |||
| 1. Updates server profile 'profile_san' to match its original state on step 1, removing data volume identified by id 2. | |||
There was a problem hiding this comment.
Updates server profile 'profile_san' to match its original state on step 1, removing the data volume identified by id 2.
Description
Examples for creating server profile with boot from SAN, migrate volume from one hw to another and migrate server profile from one hw to another
Issues Resolved
NA
Check List
$ ./build.sh).